cat -n apps/web/pages/api/webhook/app-credential.ts

# Check for other webhook handlers to see if method guards are common
find apps/web/pages/api/webhook -name "*.ts" -type f | head -10

# Look at a few other webhook handlers to see patterns
head -35 apps/web/pages/api/webhook/*.ts | grep -E "(method|POST|safeParse|parse)" | head -20

# Check if there's a pattern of using safeParse vs parse in the codebase
rg "\.safeParse|\.parse\(" apps/web/pages/api --type ts -A 2 | head -40

# Check if there's a global error handler or middleware in the API routes
find apps/web/pages/api -name "_*.ts" -o -name "middleware.ts" | xargs cat 2>/dev/null | head -50

# Verify Zod parse behavior - check if parse throws
rg "parse\(" apps/web/pages/api --type ts -B 2 -A 3 | grep -E "(try|catch|parse)" | head -30

# Check if other webhook handlers have method guards
fd "webhook" apps/web/pages/api --type f -name "*.ts" -exec grep -l "req.method" {} \;

# Check if webhook handlers have method guards
grep -r "req.method" apps/web/pages/api/webhook/ --include="*.ts"

# Check the actual error handling in Next.js API routes
# Look at recorded-daily-video.ts which uses safeParse
cat -n apps/web/pages/api/recorded-daily-video.ts | head -50

# Verify JSON.parse error handling pattern
rg "JSON\.parse" apps/web/pages/api --type ts -B 2 -A 2 | head -50

cat -n apps/web/pages/api/webhook/app-credential.ts

find . -type f -name "parseRefreshTokenResponse.ts" | head -20

cat -n ./packages/app-store/_utils/oauth/parseRefreshTokenResponse.ts

rg -A 5 -B 5 "minimumTokenResponseSchema" --type ts

# Let's check what z.string().toString() actually returns
# First, let's look for any tests related to this schema
find . -type f -name "*.test.ts" -o -name "*.spec.ts" | xargs grep -l "minimumTokenResponseSchema\|parseRefreshTokenResponse" 2>/dev/null | head -5

# Let's understand what z.string().toString() returns
# Check if there are any similar patterns in the codebase
rg "z\.string\(\)\.toString\(\)" --type ts

cd packages/app-store/_utils/oauth && node -e "
const { z } = require('zod');
console.log('z.string().toString():', z.string().toString());
console.log('z.string().optional().toString():', z.string().optional().toString());

// Test the schema
const minimumTokenResponseSchema = z.object({
  access_token: z.string(),
  [z.string().toString()]: z.number(),
  [z.string().optional().toString()]: z.unknown().optional(),
});

console.log('\nSchema keys:', Object.keys(minimumTokenResponseSchema.shape));

// Test with a real token response
const testResponse = {
  access_token: 'token123',
  expires_in: 3600,
  refresh_token: 'refresh123'
};

console.log('\nTesting with real response:', testResponse);
const result = minimumTokenResponseSchema.safeParse(testResponse);
console.log('Parse result:', result);
"
</parameter>

# Let me check what toString() returns for Zod objects
# First, let's look at the package.json to understand dependencies
cat packages/package.json | head -30

# Find package.json files
find . -name "package.json" -type f | head -5

# Let me search for Zod documentation or examples in the codebase
rg "z\.object" --type ts -A 3 | head -50

# Let me search for how token responses look in the codebase
rg "access_token\|refresh_token\|expires_in" --type ts -B 2 -A 2 | head -80

# Let's verify what z.string().toString() actually produces
python3 << 'EOF'
# Simulate what happens with z.string().toString()
# In JavaScript, calling toString() on an object typically returns something like "[object Object]"

class MockZodSchema:
    def __str__(self):
        return "[object Object]"
    
    def __repr__(self):
        return "[object Object]"

mock_schema = MockZodSchema()
print("What z.string().toString() likely returns:", str(mock_schema))

# Now let's think about what the schema would look like:
schema_keys = {
    "access_token": "z.string()",
    "[object Object]": "z.number()",  # This is the computed key from z.string().toString()
    "[object Object]": "z.unknown().optional()"  # This would overwrite the previous
}

print("\nSchema keys after evaluation:", list(schema_keys.keys()))
print("This means the schema expects these literal property names:")
print("1. 'access_token'")
print("2. '[object Object]'")

# A real token response would have:
real_token = {
    "access_token": "token123",
    "expires_in": 3600,
    "token_type": "Bearer"
}

print("\nReal token response keys:", list(real_token.keys()))
print("\nWould schema match real token?", set(real_token.keys()) == set(schema_keys.keys()))
EOF

# Let's check if there are any tests or usages that show what the schema is supposed to do
rg "APP_CREDENTIAL_SHARING_ENABLED" --type ts -B 3 -A 3

# First, let's look at the file structure and locate the file
fd "parseRefreshTokenResponse" --type f

# Read the file to see the actual code
cat -n packages/app-store/_utils/oauth/parseRefreshTokenResponse.ts

# Search for usages of this function to understand the impact
rg "parseRefreshTokenResponse" --type ts --type tsx -B 2 -A 2

# Search for usages of parseRefreshTokenResponse without file type restriction
rg "parseRefreshTokenResponse" -B 2 -A 2

# Check if refresh_token is used in other places and how
rg "refresh_token" packages/app-store/_utils/oauth/ -B 1 -A 1

# Search for where the return value of parseRefreshTokenResponse is used
rg "parseRefreshTokenResponse" --type ts -l

# Let's examine how the parsed token is used in the calling code
# Look at the office365calendar usage since it showed the usage pattern
sed -n '1,80p' packages/app-store/office365calendar/lib/CalendarService.ts | head -50

# Get more context around the parseRefreshTokenResponse call in office365calendar
rg -A 10 "parseRefreshTokenResponse\(responseJson" packages/app-store/office365calendar/lib/CalendarService.ts

# Check what happens with the parsed token - specifically the refresh_token field
rg -A 20 "const tokenResponse = parseRefreshTokenResponse" packages/app-store/office365calendar/lib/CalendarService.ts

# Let's also check the zoom usage to see the pattern
rg -A 15 "const parsedToken = parseRefreshTokenResponse" packages/app-store/zoomvideo/lib/VideoApiAdapter.ts

# Let's check the schema definitions to see if refresh_token is expected
rg "refreshTokenResponseSchema\|zoomRefreshedTokenSchema\|salesforceTokenSchema" packages/app-store/ -B 2 -A 5

# Check if refresh_token is defined in minimumTokenResponseSchema
cat -n packages/app-store/_utils/oauth/parseRefreshTokenResponse.ts

# Look for where these schemas are defined
find packages/app-store -name "*.ts" -type f | xargs grep -l "refreshTokenResponseSchema = \|zoomRefreshedTokenSchema = " | head -5

# Check office365 schema definition
rg "refreshTokenResponseSchema" packages/app-store/office365calendar/ -B 5 -A 10

# Check the zoom and google schema definitions as well
rg "zoomRefreshedTokenSchema\|googleCredentialSchema\|salesforceTokenSchema" packages/app-store/ -B 2 -A 10

# Let's trace through a specific case - how is the fake token used if refresh_token is needed?
# Check if refresh_token is actually used after being set
rg "refresh_token" packages/app-store/office365calendar/ -B 2 -A 2

# Check what happens in the zoom case with the fake token
rg "refresh_token" packages/app-store/zoomvideo/ -B 2 -A 2

# Verify the context around where the fake token is used - check the refresh flow
rg -B 5 -A 5 "grant_type.*refresh_token" packages/app-store/office365calendar/lib/CalendarService.ts

cat -n packages/app-store/salesforce/lib/CalendarService.ts | sed -n '70,90p'

cd packages/app-store/salesforce/lib && wc -l CalendarService.ts

cd packages/app-store/salesforce/lib && head -30 CalendarService.ts

cd packages/app-store/salesforce/lib && rg "import.*prisma" CalendarService.ts

cd packages/app-store/salesforce/lib && sed -n '90,105p' CalendarService.ts

cd packages/app-store/salesforce/lib && rg "prisma" CalendarService.ts

cd packages/app-store/salesforce/lib && grep -n "import.*from.*prisma" CalendarService.ts

cd packages/app-store && find . -name "*.ts" -type f -exec grep -l "import prisma from.*@calcom/prisma" {} \; | head -5

cd packages/app-store && rg "import prisma from" --type ts | head -10

cd packages/app-store && rg "CalendarService.ts" --type ts | grep -E "(import|salesforce|office365)" | head -10

cd packages/app-store/office365calendar/lib && head -30 CalendarService.ts | grep -E "^import"

cd packages/app-store/zohocrm/lib && head -30 CalendarService.ts | grep -E "^import"

# Find the file and check its structure
find . -type f -name "CalendarService.ts" | head -5

# Search for refreshOAuthTokens definition
rg -n "refreshOAuthTokens" --type ts --type tsx -A 5 | head -50

# Read the specific file around the mentioned lines
fd "CalendarService.ts" --exec cat -n {} \; | sed -n '75,110p'

# Find the zoho-bigin CalendarService.ts file
find . -path "*zoho-bigin*" -name "CalendarService.ts" -type f

# Also search for refreshOAuthTokens to understand its definition
rg -n "export.*refreshOAuthTokens|function refreshOAuthTokens|const refreshOAuthTokens" -A 10

# Search for the zoho-bigin directory structure
find . -path "*zoho-bigin*" -type f | head -20

cat -n ./packages/app-store/zoho-bigin/lib/CalendarService.ts

cat -n ./packages/app-store/_utils/oauth/refreshOAuthTokens.ts

# Verify that CredentialPayload has userId field
rg "type CredentialPayload|interface CredentialPayload" -A 15

# Check if credential.userId is used elsewhere in zoho-bigin or similar services
rg "credential\.userId" packages/app-store/ | head -20

# Check how zohocrm and other similar services pass userId to refreshOAuthTokens
rg -B 5 -A 5 "refreshOAuthTokens.*credential\.userId" packages/app-store/

# Also verify the CredentialPayload structure from the Prisma select
cat packages/prisma/selects/credential.ts | grep -A 50 "credentialForCalendarServiceSelect"

# Search for how zohocrm and other services call refreshOAuthTokens
rg "refreshOAuthTokens" packages/app-store/zohocrm/ -B 3 -A 3

# Also check hubspot and googlecalendar
rg "refreshOAuthTokens" packages/app-store/hubspot/ packages/app-store/googlecalendar/ -B 3 -A 3

# Get more context on zohocrm, hubspot and googlecalendar calls to refreshOAuthTokens
rg "refreshOAuthTokens\(" packages/app-store/zohocrm/lib/CalendarService.ts -A 10

rg "refreshOAuthTokens\(" packages/app-store/hubspot/lib/CalendarService.ts -A 10

rg "refreshOAuthTokens\(" packages/app-store/googlecalendar/lib/CalendarService.ts -A 10

# Get the full refreshOAuthTokens call in zohocrm to see what it passes as third param
rg "refreshOAuthTokens\(" packages/app-store/zohocrm/lib/CalendarService.ts -A 15 | head -25

# Get the full refreshOAuthTokens call in hubspot to see what it passes as third param
rg "refreshOAuthTokens\(" packages/app-store/hubspot/lib/CalendarService.ts -A 15 | head -25

# Check how googlecalendar handles the response
rg -B 2 -A 5 "const token = res\?\.data" packages/app-store/googlecalendar/

# Check hubspot response handling more carefully - why does it access properties directly?
cat -n packages/app-store/hubspot/lib/CalendarService.ts | sed -n '50,100p'

# Look at the hubspot HubspotToken type definition
rg "type HubspotToken" packages/app-store/hubspot/ -A 10

# Look for HubspotToken definition in callback.ts
cat -n packages/app-store/hubspot/api/callback.ts | head -100

# Also check how hubspot's refreshAccessToken is being called and what it returns
rg -B 10 "const hubspotRefreshToken" packages/app-store/hubspot/lib/CalendarService.ts | head -30

# Confirm the issue by checking what happens when refreshOAuthTokens returns a fetch Response
# Let me see if there's any response normalization in other services
rg "parseRefreshTokenResponse|\.json\(\)" packages/app-store/googlecalendar/lib/CalendarService.ts -B 3 -A 3

# Check if there's any other handling of fetch Response in the codebase
rg "response\.json\(\)" packages/app-store/_utils/oauth/ -B 3 -A 3

# Check the APP_CREDENTIAL_SHARING_ENABLED constant
rg "APP_CREDENTIAL_SHARING_ENABLED" packages/lib/constants.ts -B 2 -A 2

# Look at parseRefreshTokenResponse to understand the pattern
cat -n packages/app-store/_utils/oauth/parseRefreshTokenResponse.ts

# Final verification: confirm that credential.userId exists in zoho-bigin's constructor
cat -n packages/app-store/zoho-bigin/lib/CalendarService.ts | sed -n '43,65p'

# Verify that the proposed fix logic for response normalization is sound
# by checking what a fetch Response looks like vs AxiosResponse
rg "const tokenData.*data.*json" packages/app-store/ --type ts -B 2 -A 2